Schibsted YAMS
How to build and maintain a thousands/req service with minimal dedication
Who are you?
I'm sorry. I did NOT write BSD
So... I work
... I (some kinda) teach
... I (try to) program...
... I (would like to) rock...
... and I live
So... I value my time (a lot)
I really don't like to waste it
- Resolving incidents
- Reactive work
- Repetitive work
Schibsgrñvahed..WHAT??
What is Schibsted?
And SPT?
It's about convergence through global solutions
What's behind global components / services?
You build it, you run it
Nothing new in the horizon probably for you
- first mention in 2006, by Werner Vogels / Amazon
- Nice elaboration behind the rationale here
That means there's no ops/support/systems/devops team
{
"format": "webp",
"watermark": {
"location": "north",
"margin": "20px",
"dimension": "20%"
},
"actions": [
{
"resize": {
"width": 300,
"fit": {
"type": "clip"
}
}
}
],
"quality": 90
}Why not offline transformations?
- Lots of (user) contents. Reprocessing hurts
- Sites are dynamic by nature. Some of them do adapt the content to the device.
This may sound familiar to you...
CDNs able to transform contents on the fly:
- As a native functionality...
- Or through lambdas / edge computing
SaaS solutions:
Opensource solutions:
So...
Why did you invest time on that?
Why are you here?
Availability
Low latency
Low costs
High usage
Does not require high maintenance
- (Almost) No incidents.
- New sites do not require high onboarding efforts.
We would be able to maintain this with half an engineer
We don't (usually) like to cut people in half, so let's say one engineer
But be careful: if you stop developing a service, you kill the service
- Stops being competitive
- It quickly becomes legacy
- Disconnects from current business needs
So we try to convince the company it requires, at least, the focus of two engineers.
But oncall rotations
Ok. Let's say 3-4. And we accept an extra project.
And we are the owners of the backlog
Despite sometimes is not so useful... 